Implementing access control within a database management system (DBMS) places restrictions on which users have access to specific systems, resources, and applications connected to the DBMS. An access control model is a set of criteria that a system administrator utilizes to define system users' rights to access particular data within a database.
One access control model uses SQL GRANT statements to indicate which users have the right to access particular target objects. The GRANT statement supports columns as the target object for an object privilege, as shown in the following example:                GRANT <privilege> ON <object> (<column> . . . ) TO <grantee list>However, a GRANT statement is generally only supported for INSERT, UPDATE, and REFERENCE privileges. In addition, a GRANT statement only allows column-level DML, privilege, and a user can be only granted privilege on all the values of the column. Hence this model does not support allowing DML operations on only part of the values within a column.        
Another access control model is the Virtual Private Database (VPD) model, which allows granting DML privileges on a subset of the values of a column in a particular table by associating a policy PL/SQL function to the particular table. Administration of fine-grained access control (or control that allows operation over only part of a column of data) with VPD can be cumbersome, since the PL/SQL policy function that defines access control privileges for a given table must be developed with procedural logic to identify those rows in which a particular column-level DML operation is allowed.
Furthermore, using VPD for fine grained access control on DML operations when multiple columns of a table are involved is complicated, since VPD only allows a single policy function to be defined for a given VPD policy on a table. The PL/SQL function defined in the policy for the table is applied to all of the columns in the table. To enforce different policy functions on different columns of a particular table, multiple VPD policies are needed. Thus, in order to implement column-level SELECT privileges on multiple columns of a given table, multiple VPD policies are implemented, with different PL/SQL functions, using the same VPD statement type (i.e., SELECT). Because VPD polices are always ANDed, column-level DML policies can only be expressed for rows where all the column policies are satisfied for the row.
Yet another access control model is the User Privilege model, which allows fine-grained access control on a database object (table or view). (fine-grained means column-level privilege.) The User Privilege model provides fine-grained access control for table data by allowing definition of column-level privileges and also by allowing row-sets in the table to be paired with access control lists (ACLs).
A row-set is represented with a SQL predicate and is termed a “data realm”. An ACL includes information indicating grants or denials of privileges to user roles and/or to particular users. Privileges that may be granted include SELECT privileges and column-level privileges described in further detail below. In this way, data realm and ACL pairs comprise a data security policy that dictates what cells are and are not included in a results set to a given user.
During execution of a user's query over a given table, the table, which is the object of the query, is replaced with a view definition. For each protected column, the view definition introduces a virtual column that represents the original value of an associated column from the table, which value is only shown to the user that submitted the query if the user is authorized based on the applicable data security policy.
As such, currently, User Privilege data security policies are only applicable for fine-grained access control of SELECT privileges, and it is infeasible for data change operation-type privileges (such as privileges for INSERT, UPDATE, and DELETE operations) to be enforced using User Privilege data access policies. Specifically, replacing the object of an executed statement with a view definition that represents values in the table with virtual columns, as described above, cannot be used for fine-grained access control on data change type access modes because data change operations cannot be enforced on virtual columns (since such operations on virtual columns are not defined).
As such, it would be beneficial to enforce a user privilege-type access control model, such as User Privilege, that allows fine-grained control of data change operations without requiring development of cumbersome PL/SQL functions to implement data security policies and attaching the functions to individual tables, as with VPD.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.